With the introduction of new network technologies, the spreading of services and applications grows in number and complexity. On the other hand, mobile devices supplied by different manufacturers are expected to be more and more divergent in performance, input and output capabilities, network connectivity, processing power, and many other capabilities.
As a result of this device heterogeneity, client devices may receive contents from different applications and services, that they cannot store, that they cannot display, or that it takes too long to deliver over the supported network technology.
Some applications and services need to know characteristics of the terminal used to access the network in order to be able to adapt contents and services to the capabilities of the user terminal, thus improving end-user satisfaction and optimizing network resources.
The standardization body for Wireless Application Protocol (WAP), which is generally known as the WAP Forum, specifies a mechanism incorporated in the WAP2.0 technical specification to enable an end-to-end flow of a User Agent Profile (hereinafter UAProf) between a WAP client, intermediate network points, and an originating server. This User Agent Profile includes a set of terminal capabilities information. Heretofore, this is a partial solution to the problem of letting the applications and services know about terminal capabilities, since it is only valid for WAP applications and WAP terminals. However, UAProf proposes an end-to-end negotiation of terminal capabilities between the application server and the mobile terminal, thus increasing traffic load and latency time whenever a new service is accessed.
In addition, the new Mobile Execution Environment (hereinafter MExE) specification within the 3rd Generation Partnership Project (3GPP) describes an application environment for the latest generations of mobile devices. This MExE comprises a variety of current technologies and incorporates both WAP and Java, including also a framework which specifies, among others, capabilities and contents negotiation.
Different technologies follow different mechanisms in order to provide those applications running on top of such technologies with terminal capabilities information intended for adapting contents to particular terminals. That is the case of both WAP and MExE above. The use of UAProf, for instance, is widely spread around these technologies, and generally accepted as a convenient solution to the problem of representing and exchanging terminal capabilities information. Other suitable mechanism under WAP or MExE is the so-called Composite Capability Preference Profiles (CC/PP), which is an application of the extensible Mark-up Language (XML) used to describe capabilities and preferences associated with a user, and the agents used by a user to access the network. These user agents include the hardware platform, system software and applications used by the user. User agent capabilities and references can be thought as meta data or properties, and descriptions of the user agent hardware and software.
Despite the current trends of using solutions based on UAProf or CC/PP, these technologies above implement such solutions in a proprietary manner, making each solution incompatible with the others. Moreover, these solutions propose that a dialog for negotiating terminal capabilities is directly established between the terminal and each application server, making it necessary to the terminal the sending of such terminal capabilities to any new application server that the user wants to make use of. This leads to an unnecessary increment of traffic from terminal equipment to application servers and consequently to an increase on the latency time when accessing a service, what is more significant in a mobile environment.
In addition to this, the terminal equipment has to implement a new protocol for negotiation of terminal capabilities for every different technology. In other words, a terminal equipment implementing WAP and MExE has to implement UAProf and/or CC/PP for WAP and for MExE.
The international application WO 99/41931 describes a mechanism for an application server to deal with terminal capabilities. This application proposes a peer-to-peer mechanism between the terminal and the server to let the server know the terminal identifier by using an Unstructured Supplementary Service Data (USSD) message included in the Mobile Application Part (MAP) protocol. The server assumes the responsibility to look for terminal capabilities outside the mobile network and based on said terminal identifier. Thus, the establishment of a relation between the user identity and the terminal identifier is not solved. Terminal capabilities information is related in no way with the rest of the user profile, forcing the application server to use different mechanisms to access user profile and terminal capabilities.
Moreover, the European application EP 1 051 054 describes a mechanism for allowing the use of a service, or for adapting the service behaviour, depending on the terminal capabilities and the specific location, by accessing to certain databases tracking the mobile equipment and the geographic location. However, this mechanism only provides a reference of the equipment model to the application server, leaving to the application the responsibility of obtaining the specific terminal capabilities. Moreover, the invention does not solve the establishment of relations between the user identity and the terminal equipment identifier.